1. Field of the Invention
This invention relates to method and apparatus for optimizing a heap size, and program and program recording medium thereof, and more particularly to method and apparatus for automatically optimizing a heap size, and program and program recording medium thereof for obtaining an optimum heap size in a computer system that implements a garbage collection.
2. Description of the Related Art
Hereinafter the term garbage collection is abbreviated to GC. Examples of computer systems that implement GC include JVM (Java Virtual Machine, Java:trademark). While the present invention will be described herein with respect to a JVM as an example of computer systems implementing GC, the systems to which the present invention can be applied are not limited to JVM.
In general, it has been difficult to estimate (predict) the amount of memory required for programs such as Java programs that dynamically reserve memory (for example, see non-patent document 1).
Among the measures of the performance of a computer running applications, a throughput and a response performance are impacted by GC. The term “throughput” herein refers to the amount of work processed by an application per unit time. The term “response performance” herein refers to the uniformity of the time between an input by a user to an output to the user. The more uniform the time is, the higher the response performance is.
During GC, a user program is stopped. If the starting frequency of GC is high, the throughput decreases because the user program stops every time when GC is started. Therefore, to improve the throughput, a larger heap size is desirable to decrease the starting frequency of GC, which is a cause of reduction in the throughput.
On the other hand, to improve the response performance, a smaller heap size is desirable to reduce processing cost per GC. This is because high processing cost per GC increases the time during which the system pauses due to the blockage of the heap by GC. If GC is not running when a transaction is provided from the user, the system can immediately respond to it. If GC is running, the system cannot respond to the transaction until the GC ends. If processing cost per one GC is high, a response time to the user during GC and a response time to the user not during GC are not uniform. Then, response performance lowered.
To solve the above described problems, the following measures have been taken. In order to improve the throughput, the heap size is set larger. In order to improve response performance, the heap size is minimized as small as possible. However, it is impossible to simultaneously meet these mutually contradictory conditions. In practice, it is extremely difficult to obtain a necessary and optimum heap size.
Therefore, a conventional practice is as follow. The heap size is increased when a heap shortage is caused, and the heap size is decreased when the response performance is degraded due to GC performance degradation caused by an enormous heap size, then each time the heap size is increased or decreased the system must be rebooted.
Further, it is a prior art that GC is frequently performed to reduce object drag time (the lag between the time an object is last accessed and the time it is collected by GC during which the heap is used unnecessarily) (for example see non-patent document 2). This is an approach to reduce the time lag (herein drag time) and to process in the Java application on a JVM. However, frequently running GC places a large burden on the system, thereby extremely reducing the throughput.
Non-patent document 1 is “Save Memory Programming, Software Patterns for System with Limited Memory” by James Noble and Charles Weir (Piason Education, p. 269).
Non-patent document 2 is “On the Effectiveness of GC in Java” by Ran Shaham, Elliot K. Kolodner, and Mooly Sagiv (The 2000 International Symposium on Memory Management (ISMM'00), October 2000).
The prior art approaches described above cannot automatically determine any optimum compromise between the throughput and the response performance when a given Java application is executed. Moreover, they provide a poor accuracy of heap estimation and require a number of trials until an optimum heap size is found, resulting in an enormous work cost.